Pay-Per-Feature License Model

Developing Applications Using The SoftwareShield System > Creating Licensing Solutions > Available License Models > Pay-Per-Feature License Model

## Pay-Per-Feature License Model

This model allows you to deliver software for which a user must individually pay for features. "Features" can be as simple as the functionality behind a button click or the ability to dynamically load a binary module. In this model features are completely independent from one another and can be individually purchased and activated or treated as a group.

### Overview - How to Integrate the Pay-Per-Feature License Model Into Your Application

There are at least two basic mechanisms to integrate the Pay-Per-Feature License Model into your application. In either one, you will use a secure license state to serve as the "feature lock" for each feature you want to protect. If the feature lock is not activated - you do not allow the user to access the feature; once activated - they can of course use the feature.

Either way, you will use General Use Authorization Definitions to control your features. However, there are two approaches to this model:

1. Use multiple General Use Authorization Definition to represent your protected features - one for each. The maximum number of features you can protect this way is 64.

2. Use a single General Use Authorization Definition and interpret the Stored Parameter Value in that definition as a bit-field representation boolean flags, each bit representing a single protected feature. The maximum number of features you can protect this way is 1024.

Once you have decided your basic approach, design the license:

1. The first step is to ensure that your license has the necessary Authorization Definitions built into it. Depending on your approach, create a number of General Use Authorization Definitions. If using the first approach, the parameter is optional and may be used for any tertiary purpose for that feature. If using the second approach the definitions must use parameters (for the bit field). In the second approach, be sure to carefully document which bits represent which features.

2. Once you are satisfied with your license, compile a distributed copy of it. The distributed copy is encrypted and compressed and only contains absolutely necessary information for the enforcement of your license. Place a copy of this distributed license in your applications directory. If you have decided to use steganographic alias files, make sure that they are also in the application directory. Have a look at the programming notes file that the SoftwareShield License Manager creates for your specific license. This will make your programming a little easier by supplying you with the code you will need to invoke the start up event. Please see Deploying the License for Your Application for more detailed information about deploying your license.

3. Next, in your programs startup event (main form load etc.) create an instance of the ClientProtector object and immediately call its StartUp function. You will have to pass specific parameters such as the license name, main license file password, and the finger print options code - but this code will have been already written for your convenience when you compiled your license - just look in the programming notes file created by the SoftwareShield License Manager. Have a look at the exact details of the StartUp function for more information on making this call.

4. Now, once the ClientProtector StartUp call returns and the license state is as you expect it to be - determine which features (if any) are activated:

1. Call GetAuthorizationDetails or GetAuthorizationDetailsEx for the General Use Authorization Definition(s) you have defined to hold the state of your feature activations.

2. If you are using the first approach, check the Activated state of each features definition, to determine if the feature should be accessible by the user.

3. If you are using the second approach, interpret both the Activated state and the stored parameter value (as a bit-field of boolean values) to determine which features (if any) are activated.

5. To Activate the users license and turn features on which they have paid for, you have a few options:

1. If using the first approach, the best way to turn on multiple features at once is to use a Run-Time Composite Authorization Definition. Or you can individually activate them using an Activation Code generated directly against the target definition.

2. If using the second approach, you will have to construct numeric parameters that represent the bits you want to turn on. E.G.: Numeric parameter 13 (binary 1101) may turn on features #0, #2, and #3. Note that in this example feature #2 will be "turned off" unless you combine the bits from before and after the activation with a bit-wise OR operation. Depending on your business requirements - this may or may not be desirable and is left up to the programmer to manage.

3. If you need to, you can always programmatically manipulate this license state data directly using: SetAuthorizationDetails and SetAuthorizationDetailsEx.